Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/More Source/C⁄C++/Xconq 7.0d37/doc/PROJECTS

Text File | 1995-05-04 | 109KB | 2,757 lines

PROJECT IDEAS

--Overall

Be able to resign without losing all units (but what effect
then? defined by game?).

--GDL

Define a global "side*" that is a list of all sides.

In evals, give meaning to "this" so expressions like (count <u> (this side))
work.

Could restrict some tables to 15 bit integers, use top bit to repn varying
value, up to 16d15+127 by doing a 4/4/7 split of bits.

Support full decimals for parms, flush the "10000" numbers and add scale
factor to all numeric parms.  Scaling fixed by code, use scaling when
computing effects.
Ambiguity if context of decimal doesn't include scale factor (as in "define"),
but could support decimals as a distinct type in GDL (as ratios instead of
floats?).  c_number should convert to integer, or check validity of uses.

When conditionally not loading, should not intern symbols or alloc strings.
(use a global to test in lisp.c - must read well enough to recognize the "end-if")

Error messages should include context as well as line numbers (save previous
several lines, and dump next several if still reading after error).

--Types and Objects

When restoring a game, record which sides get which players (if recording
that), and that game was restored, but do nothing further for events.

Climate-related global vars should become world or area properties.

Need a way to indicate that some types are never available in a game,
cache in arrays u_available[], etc, test internally, etc.
Also need a per-turn test to see what is currently available.

Notify display when cover goes to/from 0 (but excessive, since coverage
always cleared then restored later).

Add a controlled-by layer to world that can be distinct from people side.
Control can be imposed by presence of particular units within a given
range, maintained by others to a given range, with chance of reversion
to people side if different from controlling side.

Define unit->origside, indep of politics/feelings, use in reporting,
liberation, etc.  Captured unit goes to origside if trusted or friendly
to capturing unit's side.

Define unit feelings toward each side as pair of bytes, for/against and
willingness to act on feeling.

Clarify vision rules.  The true state of the world is a set of layers.
For each cell in each layer, there is an apparent value, a date for
that value, possibly prev values also.  Only need bit if value always
accurately known once discovered.  Elevations and features unlikely
to change, but weather, units, people, material often inaccurate.
directly_visible(side, unit)
implies that unit is accurately seen.
chance_to_see{,_on_movement,_on_action,_each_turn}(side, unit)
if always 100%, then is equiv to directly_visible.

Define a unit->tracking slot that is a sidemask of sides that are
seeing the unit move around.  (Unit property "trk".)
#define side_tracks_unit(side,unit) (unit->tracking&side_bit(side)).
Define u_track_chance, defaults to 0.
Define u_lose_track_chance, evaluate once/move, once/turn.
If unit being tracked, then updates about unit state go to all
tracking sides.
Track bit would always be set for own units.

Implement storms as very-high-density cloud (>100%?).  Storms cause
accidents and attrition.

Impl constant elevations and temps that don't need a whole layer.
Detect by seeing min == max of terrain types present (and no chance
of terrain changes - test this in general).

Allow some moves to use random mp, be able to specify +/- amounts.
This is mp (and acp?) consumption only, does not affect validity of action.
ut_mp_extra?

Define a notion of hp for bord/conn types, allows for interdiction
and repair.

Side library should be able to allow multiple usages of some members.

Define a hallucination chance for some utypes:
(sp-)looks-like u1 u2 -> n% is chance that u1 appears to be a u2
and is recorded as such in a view.
Note that code should ensure that only info about image is displayed
rather than hallucination.

Use a slot (which?) to indicate variation radius of actual reinforcement
position around  given xy.  Default of zero requires to be on actual xy.

Implement ZOC as a layer if any ZOC ranges > 1.

Add a new layer coveralt to indicate the lowest altitude visible
to any unit on the side.  Adjust along with basic coverage.

Add a "facing" bitmask that indicates the directions that a unit is
"facing", or can operate in, add effects of facing vs non-facing.
Come up with a display for this.

Events can have causes that they should be tied to, can use to
enhance displays etc.

Allow a symbol for reference to sides.
Syntax is (side <n> [<symbol>] props...).

Add a (x (symbol <sym>)) to units that can be used to write a symbolic
ref to unit when saving.

Maintain an in-supply bit for units.

Add chance that incomplete units will lose cp (eliminating if cp == 1),
call it incomplete-accident-chance.

To decide about control, see if any units cannot always be controlled
directly, then for those compute the max radius that controlling units
can be in.  If > 1, should define a layer, otherwise check directly
when need to know.

Some unit types should be unwilling to break a treaty.
(In some games,)
Should humans have to declare war explicitly?
DoW may not be possible or meaningful in some games...
DoW is agreement by single player doing the declaration, terms are to
treat side as enemy (doctrine), and to hit other side (how often?),
could demand a surrender of some sort.
DoW must be public.
Up to other sides how to respond.
Peace treaty includes terms to nullify DoW.
In general, terms should be able to include refs to other agreements.
DoW can always be rescinded by player alone, make it have morale
consequences?

LOS always sees straight overhead perfectly, so calculations really
figure how how low to the ground is visible at any point.

Could add a bit vector to spottable units indicating which sides
are tracking.

For each unit type, add a property that indicates fate of unit when
side leaves the game - change side, disappear, no change.

@deffn Table @code{people-sabotage-rate??} u m -> .01hp
This table is the attrition rate of a unit in the open in
a cell with people on a hostile [define] side.
@end deffn

DEF_UPROP_I("lockon-chance", u_lockon_chance,
    "chance that unit remains seen when no longer covered",
    lockonchance, 0, 0, 100)
@deffn UnitTypeProperty @code{lockon-chance} n%
This property is the chance that once seen, a unit will continue to be seen
while it is being covered.
Defaults to @code{0}.
@end deffn

DEF_UPROP_I("storage", u_storage,
    "space for materials shared by all types",
    storage, 0, 0, 9999)
DEF_UM_TABLE("material-size-in-unit", um_size,
    "how much space one unit of a material requires in a unit",
    umsize, constumsize, 0, 1, 9999)
@deffn UnitTypeProperty @code{storage} n
This property is a unit's generic space for materials of any type.
Defaults to @code{0}.
@end deffn
@deffn Table @code{material-size-in-unit} u m -> n
This table is the amount by which the given material counts against
the unit's storage space.
Defaults to @code{1}.
@end deffn

DEF_UT_TABLE("capacity-negation", ut_capacity_neg,
    "true if the unit negates capacity of connections of the terrain type",
    utcapacityneg, constutcapacityneg, 0, 0, 1)
[, but some unit types negate the capacity of connections.]
@deffn Table @code{capacity-negation} u t -> t/f
This table is @code{true} if when @var{u} is in the open in a cell
that includes connections of type @var{t},
those connections have no capacity for units.
Defaults to @code{false}.
@end deffn

Implement (or stub) basic goal tests.

Implement doctrine locking.

Terrain types should have a precedence determining which conn/border types
override each other's effects (right now any conn overrides any border).
Should be a property of ttypes.

Side relations could be expressed as a bit vector of what will happen
in various situations.  "wake up if approached", "allow entry", "exchange
view info", etc.  Particular relationships such as trust and control
become particular bit vectors then. (or could do as defcon levels?)

Need a way to have an OB with lots of units, followed by refs to
particular units and modified properties, and read both without
creating any useless units.

--Setup

In elevation setup, map raw elevations to min of range for ttype,
stretch so values are even through range.

When opening a game module, add its directory to the list of directories
to search for included modules.

Assign numbers to numbered units after all are read in.

Add a command-line option to interpret forms supplied on the command line.
Do these after all else read and interpreted and variants done.

Each side should be able to get different instructions.
Per-side instructions should not be accessible to other sides.

Should use elevation diffs to decide about sloping-type terrain.
Add to basic percentile algorithm.

Add a "spur" phase to road gen that connects to nearest road.

Add a chance for roads that just cross the area from one edge to
another.

If a next dir for a road has a possibility to connect to a unit
of a type that roads connect to, choose the dir to that unit over
any open terrain direction.

Roads should be able to run in non-closer dirs for a small number
of steps.  Should also look ahead to pick overall most favorable
routing.

Player mix test should be allowable_player_mix(assignmentindex),
allows "scapegoating" a particular player if failed - gives
a starting place for interface to fix.

Define parms for variability of initial materials using variation
on fractal percentile synth method.

Change random renaming to offer a list of choices, but not to load
all the emblems.

Liquid adjacent terrain types should always even out to same elevation
(highest or average of all the competing elevations?)
Flooding is always instantaneous if ttypes changed by a unit.
Non-liquid border might or might not be a dike.

Add density of occupants of indep units already placed.  Specify for
both units that have to be occs and others that don't.

Need a way to coordinate all name gen for a single side -
"foo" -> Fooland, Fooard, Fooards, Fooish"  Could also decide colors and
emblem randomly, but wouldn't need to coordinate.
Specify just *one* side name generator, extensions added in a standard
way by an nlang.c routine.
Predefine nonterminals side-name, side-noun, etc in side-namer grammar.

Add "earthlike" generator that borrows code, but is completely wired
to do Earthlike stuff, including a semi-wired set of terrain types
(use extensions to recognize by attributes rather than position,
so that river deltas can be flat and swampy indep of how terrain type
fits with others in a game design).
Use tectonic code at some scales, erosion at others.
Could base calcs on sphere, translate to world grid when done.
Base on all real dimensions, so alt ranges wired.
Parameters are area size/world.circumference for the scale
(assume 100 km/cell if weird circumference),
latitude of area, range of elevations (0 - 10000 meters),
distance from coast (at center of area, allows specifying distance such that
area can be 3/4 land, etc), average temp, average rainfall.
For tectonics, use layers for plate num, move dir, and elevation.
For small-scale, make random ridge/high point, erode down to lowest
or to coast.

Could add recorded events that get played when their scheduled time
arrives, so that a city could revolt or disappear at a preset time.
Playing scheduled events should happen after acp/mp calc, but before
players actually get to move.

Kernel should be able to do a system reset - all data structures
and all allocation, so that a different game can be started up.

Add synth method for secret scorekeeper goals.

Use password to match up players when restoring into a different set
of displays.  If no password, then will just accept a different
assignment, perhaps warn for cmdline setup, flag in dialog boxes.

Any terrain-based variation, such as temperature, should check
if need to represent varying values over area, don't need to
alloc layer if not, *but* may need to quickly synth layer if
terrain is added that *does* allow variations.

Should be able to conceal the identity of side until first
encountered (still display progress in turn, helpful to play).

In percentile terrain, map raw to final elevation more smoothly,
computing min/max raw and final, stretching raw range to cover
final range uniformly.

When making units appear, do only units in open directly, then
occupants recursively once transports have appeared.
Similarly for disappearance, but in reverse order.

Add this?  What is it supposed to mean?
DEF_UU_TABLE("can-command", uu_can_command,
    "true if the type can give orders to the other type",
    uucancommand, constcancommand, 0, 0, 1)

--Actions

Unit action priority should be able to derive from individual extension
property, a per-side vector of type priorities, a per-type property,
and a per-side property.  Routine is just unit_priority(unit).
Goal is to be able to have, say, allied aircraft and German ground
units move together, then German aircraft and allied ground, then
trains and trucks of both sides.

Define action "influence" that is like proposed "charm" but more
general.

Side changing should not be a type of action.

Allow free disbanding of incomplete units.

Allow the construction of bases even when it would be necessary
to bring all units stacked in the cell inside the incomplete base,
in order to make sufficient room.
Entries should be automatic and free.

Add a uu_acp_for_pursuit to give a bonus if the victim is retreating.

Implement acp_for_retreat.  For each direction away from the attacker,
see if (acp_for_retreat + acp) * speed > mp needed to enter cell.
Do for each dir, pick workable.  But first try to retreat into transports
if possible.

Changing type should have a material cost, so peon can buy title.
Extend to material prerequisite cost for all actions? (lots of tables!)

Add a separate chance for defender to capture attacker upon counterattack.

Add a material cost um_material_per_<type> and prerequisite
um_material_to_<xxx> for all actions.

Generalized notion of fire interdiction would be useful, could subsume
effects of jammers and suchlike, also if firing is used to represent
aircraft raids, need a way to define interceptors that can reduce
the effectiveness of the raid and the amount of aircraft material
available.

To do < 1 cell/turn speeds, available acp should translate to
occasional ability to move.

Some types of combat should not be able to reduce victim hp below a given
level.  uu_min_hp_from_hit.

Define material-theft-per-contact(u1, u2, r) -> n in combat,
material-loss-per-hit(u1, u2, r) -> n which is material completely lost.
Some could be "resorbed" by terrain?

Some occ types could protect by intensifying counterattack.

Chance to surrender should be higher if damaged.

A mobile unit should be considered surrounded or cornered if adjacent
cells are either impassable or occupied by unfriendlies.  Also look for
impassable borders and passable connections.

Occupants of captured units might get to stay and not change side
if friendliness-to-enter allows it (?).

Detonation's effects should depend on altitude of detonating unit -
compute the "actual" 3d distance.

Define effects of altitude differences on all unit interactions.

Damage to multi-part units could be done by detaching wrecked-type
instead of damaging all parts equally.  Do only if wrecked-type
has appropriate sizes.  Only applies if wrecked-type has equal num
parts to original type.

Could do multi-cell move actions as repn of hex entry until
anything happens that requires a decision - blockage, etc.
example: acp = 1, mp/acp = 10, allows single move of up to 10 hexes.

If a side wins a battle, then side's units involved should gain affinity
for side, lose fear of other side.
On losing side, units lose affinity for own side and increase fear of
winning side.  Nonparticipants also affected, but less so.
Affinity increases by positive acts, fear increases by negative acts.
Betrayals should be detectable, have large effect.
Need some implicit agreements about defense of units on a side,
that players should not violate.

Side action limit should be a distinct value, decremented only for "manual"
activity by player (first action after waiting for input?).

Add a "coordination" action that adds other units to a unit's attack,
with multiplied effect.  Attack action has to look at each coordinating
unit, add effect if able to do so, and take away acp for coordinating
units also.

For variable-commitment combat, attacker effectively sets m% commitment
for self, desires n% from defender.  Defender then chooses between n1-n2%
commitment, where limits set by unit types and m%.
Possible reactions also limited by commitment - defender could disengage
at <10% commitment, say, is otherwise stuck in the battle.
Reactions are counterattack, surrender, withdraw, do nothing special,
these are (mostly) indep of damage.

Commitments default to zero.  If can be nonzero, create battle objects.

If defender counterattacks, then might exchange attacker/defender
in battle, so now defender can decide commit/withdraw.

Response to capture attempt might be to hit capturing unit?
Capture after combat is really a side effect where a unit surrenders
(implies attacking unit might end up doing the surrendering!).

Add loss of material as consequence of combat.
@deffn Table @code{theft-chance-per-attack??} u1 u2 -> n%
@end deffn
@deffn Table @code{stealable-material??} u m -> n
@end deffn
@deffn Table @code{loss-per-attack??} u1 u2 -> n%
@end deffn

Add variable commitment and then constrain it:
@deffn Table @code{attack-commit-min??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-min??} u1 u2 -> n%
These tables are the minimum limits on the initial commitment to a battle.
Defaults to @code{0}.
@end deffn

@deffn Table @code{attack-commit-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-max??} u1 u2 -> n%
These tables are the maximum limits on the initial commitment to a battle.
Defaults to @code{100}.
@end deffn

@deffn Table @code{attack-commit-up-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-up-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{attack-commit-down-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-down-max??} u1 u2 -> n%
These tables are the maximum limits on the change to commitment to a battle.
Defaults to @code{100}.
@end deffn

cxp affects both attack and defense abilities, should define
uu_cxp_{attack,defend}_effect.

Be able to control whether occupants can be attacked directly.

[need general defns for who moves and when during combat rounds]
[could potentiall acquire additional acp if move is discretionary,
also get a level of flexibility about future commitment]

[need combat's effect on tooling? uu_tp_hit_effect, can be positive
or negative (being hit helps recruiit soldiers)
just hit tp randomly as percentage of hp]

@c @deffn Table @code{cxp-hit-plus-max} u1 u2 -> n%
@c This table is the maximum hit modifier for attacker unit.
@c Defaults to @code{0}.
@c @end deffn
@c
@c @deffn Table @code{cxp-hit-minus-max} u1 u2 -> n%
@c This table is the maximum hit modifier for defender unit.
@c Defaults to @code{0}.
@c The actual hit probability equals the basic hit probability, plus
@c @code{experience-hit-plus-max} times fractional experience (i.e.
@c experience divided by maximum experience) of the attacking unit, minus
@c @code{experience-hit-minus-max} times fractional experience of the
@c defending unit.
@c @end deffn

DEF_VAR_I("actions-are-buffered", g_actions_buffered, set_g_actions_buffered,
    "",
    gactionsbuffered, 0, 0, 1)

@deffn GlobalVariable @code{actions-are-buffered} t/f
This variable is @code{true} if all the units of the same priority
must specify their actions first and then execute
them all at once,
rather than deciding and executing before the next unit gets to act.
Defaults to @code{false}.
@end deffn

DEF_UU_TABLE("material-cxp-effect", uu_material_cxp_effect,
    "effect of combat experience on material usage in combat",
    uumaterialcxp, constuumaterialcxp, 0, 100, 9999)
@deffn Table @code{material-cxp-effect} u1 u2 -> n
@end deffn

DEF_UU_TABLE("attack-elevation-effect", uu_attack_elev_effect,
    "",
    uuattackeleveff, constuuattackeleveff, 0, 100, 9999)
@deffn Table @code{attack-elevation-effect} n
Defaults to @code{100}.
@end deffn

DEF_UU_TABLE("friendly-hit-chance", uu_friend_hit,
    "base chance for a type of unit to hit a unit on a friendly side",
    uufriendhit, constuufriendhit, 0, 0, 100)
@deffn Table @code{friendly-hit-chance} u1 u2 -> n%
This table is the chance that a unit @var{u2} on the attacker's side will
be hit accidentally during an @code{overrun} or @code{fire-into}
action.
Defaults to @code{0}.
@end deffn

DEF_UU_TABLE("ambush-chance", uu_ambush,
    "chance that a unit will be able to attack by surprise",
    uuambush, constuuambush, 0, 0, 100)
@deffn Table @code{ambush-chance} u1 u2 -> n%
If @var{u1} attempts to move into a cell containing @var{u2},
then a) if can't co-occupy, this table is the chance that @var{u1}
gets a chance to attack at improved odds(?), or if b) if can
co-occupy, then @var{u1} will enter the cell, then be attacked
as in a).  The ambusher's plan can flag whether the unit
will take ambush opportunities or not.
@end deffn

DEF_UT_TABLE("mp-to-ascend", ut_mp_to_ascend,
    "mp needed to increase elevation or altitude",
    utmptoascend, constutmptoascend, -1, 0, 9999)

DEF_UT_TABLE("mp-to-descend", ut_mp_to_descend,
    "mp needed to reduce elevation or altitude",
    utmptodescend, constutmptodescend, -1, 0, 9999)
@deffn Table @code{mp-to-ascend} u t -> mp
@end deffn
@deffn Table @code{mp-to-descend} u t -> mp
These tables are the mp cost to go from the min possible elevation
to the max possible elevation in the world.
This is interpolated and rounded down.
@var{t} is the type of terrain being left.
Defaults to @code{0}.
@end deffn

@deffn Table @code{ablation} u1 u2 -> n%
This table is the amount of the hit that gets passed through
to the transport's occupants.
Defaults to @code{100}.
@end deffn

@deffn Table @code{stack-ablation} u1 u2 -> n%
@end deffn

--Backdrop

Run end-of-turn scorekeepers at end of turn 0 (right before first
turn of game)?

Add a min-hp-to-recover that is like hp-to-repair, but applies to
automatic hp recovery.

Add ut_people_supply that is amount of supply gotten by unit if people in
cell are on the same side.

Express need for limited supply as "n turns of supply before starvation"?
Can lead to tough decisions about starving rear areas for sake of major
offensives, etc.

in-length > 0 + ability to transfer from terrain should mean that unit
can get supply from cells other than own cell.  Use to get water from
adjacent land in "voyages".

Should choose side to revolt to by counting
number of units (of same type on each side?).

Siege surrender chance should be distinct from normal surrender chance.

Games should be able to define what size groups can be surrounded,
by radius or number of units.  Default to 1 cell areas.

[need to identify motives for demand, if rtype not needed
for actual survival - dyes needed for "art" for example -
might vary between sides/unit types?]
[would need to define generic elasticity of demands,
also the profit-seekingness of a population (vs conservatism, etc)]
[need some notion of credit too?]
[units can effectively forage at some distance, distinguish foraging
from actual production]
[price should go up as material is transported further and further,
and across varying difficulty of terrain...]
[note that as sides, players can't force cell economy but can
encourage it]
[perhaps allow a side to fix a price artificially, let everything
else readjust around it?]
Sides can specify their trading relationship with other sides,
by specifying the ratio of tariff to supply [etc].
[trade relationship is indep of general trust/friendliness]
[some type of agreements might be intrinsically enforceable, such as
exchanges between units that cannot attack or capture each other]
[exchange of material needs to relax fullness rules or be done as
a sort of prim, else might not be able to trade when full]

Do supply lines, display unit's supplier and maybe supply route.
Is there an efficient way to handle this?

To do large elev ranges, use bit 14 to indicate which range,
define a global that gives ratio of ranges.  Also need a descriptor
for text generation.

Add possibility to see some/all of a side's units if one of them is captured.

Weather needs pressure, humidity, calculates new values of these
and also has effects on visibility at multiple levels of atmosphere.
Need to identify effect of each terrain type (and elevation) on each
of these, also specify the rate at which changes occur.
Effects on supply.
Effect on vision, sensing in general.
Each utype has preferred weather, gradual falloff in effectiveness.
Add a generic "violence" value that summarizes wind/storm strength,
relate to unit behavior.
Use season to get avg temp, perhaps regulate motions as well.
Impl via weather phenomena - overcast/clouds, rain/snow, storms/wind,
temperature, humidity (compute value of phenomena, then compute phenomena's
effect on units).
Attrition increased by storms, also chance of accidents (for each accident
type).
Could make some types of terrain temporarily impassable.
Display should show fronts, major storms.
Impl sequence should be fixed weather (weather state), random weather,
seasonal weather, calculated weather.
Implies that player-visible/settable state layers should be implemented first.

Compute a daily temperature cycle based on number of daylight hours etc.

@deffn UnitTypeProperty @code{weather-vision-range} dist
[should be a table so can't see a long ways off from within forest?]
@end deffn

The primary effect of clouds is to make things harder to see.

@deffn UnitTypeProperty @code{vision-cloud-effect} xxx
@end deffn

Be able to play back a recorded sequence of weather during a game.

Distinguish "ideal" material level from "max" level, let
some percentage of material move towards comfortable areas.

Scorekeeper can forbid the saving and restoring of a game, use in
nonsecure situations.

Add a scorekeeper that looks at side view to decide whether player has
discovered something that is to be searched for.  Should be able to
require finding a lost city, etc.

Add option to scorekeeper to run on success/failure of an action
matching given parameters, plus option to run on occurrence of a specified
events, otherwise scorekeeper runs at either beginning or end of turn.
Matching includes side and unit.

Add formal notion of money as a type of material that is global to a side,
has no physical repn.  Materials such as gold can have a monetary value.
Sides can force exchange rates or let float.

Add a "plague" random event/process that randomly spreads and moves around,
use for fires, plagues, floods, etc.
Could track state/progress by material layer or a "severity" layer.
Perhaps use coating terrain for this?

[random clouds, etc]

[have random storms, increase chance in weather extrema if they occur]

DEF_TM_TABLE("supply-move-rate", tm_supply_move_rate,
    "",
    tmsupplymove, consttmsupplymove, 0, 0, 0)
@deffn Table @code{supply-move-rate} t m -> n
This table says how much of material @var{m}
can be moved through terrain @var{t}
(cell, border, or connection) in each material transfer action.
The actual limit is the minimum of all cells and borders
along the supply route.
A value of @var{-1} allows any quantity to go through.
@end deffn

DEF_UM_TABLE("supply-interdiction", um_interdiction,
    "",
    uminterdiction, constuminterdiction, 0, 0, 9999)
@deffn Table @code{supply-interdiction} u m -> n%
This table is the reduction of supply due
to the presence of an enemy unit of the
given type on the supply line.
A value of @code{100} means that the unit has no effect on supply movement,
a value of @code{0} means that the supply line is completely cut.
Defaults to @code{0}.
@end deffn

DEF_UU_TABLE("spy-see-always-chance", uu_spy_see_always,
    "",
    uuspyseealways, constuuspyseealways, 0, 0, 100)
@deffn Table @code{spy-see-always-chance} u1 u2 -> n%
This table is the chance that if @var{u1}'s spies return information
about a unit of type @var{u2}, then that unit will always be
visible thereafter, as if it were @code{see-always}.
The compromised unit and its side will not be aware that
this has happened.
Defaults to @code{0}.
@end deffn

@deffn UnitTypeProperty @code{spot-movement} t/f
If this property is @code{true},
then the unit's chance to be seen by other sides will be
tested each time the unit moves.
@code{spot-action} implies @code{spot-movement}.
Defaults to @code{true}.
@end deffn

@deffn UnitTypeProperty @code{spot-combat} t/f
If this property is @code{true},
then the unit's chance to be seen by other sides will be
tested each time the unit engages in combat.
@code{spot-action} implies @code{spot-combat}.
Defaults to @code{true}.
@end deffn

@deffn Table @code{see-combat-chance} u1 u2 -> n%
This table is the basic chance to see a unit of type @var{u1} when
in combat with a unit of type @var{u2}.
The location of @var{u1} must be covered by some unit on the viewing side.
This is evaluated for each combat action within a turn.
Defaults to @code{100}.
@end deffn

--Plans and Tasks

Add to move task to distinguish between "move and enter" and "move in open".

In some circumstances (which?), allow plan-tweaking commands to
create and fill in the plan for an incomplete unit.

Add an ability to store and act on dated future plans and goals.
Need to be able to evaluate preconditions for plan, so can do only
if makes sense.

Doctrine and unit plans should include rules about when units should
attack automatically.  Should be careful or will lose units to foolish
actions.

Attack tasks should go after undamageable units,
if less than perfect protection, damageable visible occupants.

Check on likely success of resupply task, if dubious, commit to forward
motion.  Consult AI or human prefs?

Defense plan should identify what is defended, and what are the threats.
If no threats, unit just tries to stay healthy.
Defender's search for threats should cover a radius computed from
defender's and ward's positions, areas covered by view, speed of threats
(need to see bombers *before* they reach cities, can attack and retire
before anybody can react).
Threats can be recognized directly, or gotten from AI's list of threats.
A unit is a threat if
1) it can capture or damage the ward
2) it can cut the ward off from supply or other defenders
3) it can hurt the defender
To respond to a chosen threat, can 1) attack the threat, 2) interpose,
3) move the ward, either on own or by carrying.

Do better resupply algorithm.  Unit should decide what materials it
needs, and in what time frame, picks ideal locations to get materials
from, then if at one, waits or transfers supply in.

Do a large sideways move if all immediate directions are blocked.
Only do once or twice before task fails.

"Intercept/defensive" plan directs units to patrol in an area, attacks any
enemy unit (doctrine defines "enemy") that is of a type that can be
attacked/harassed/blocked (ignore types that we can't do anything about!)
Only some kinds of defensive units are interceptors, others are blockers
or kept in reserve.  Blockers interpose rather than attack enemies,
while reserves avoid contact until plan is changed.  Defn of "reserve"
partly depends on attacker, so fighters intercept bombers but ignore
battleships.
Do as explicit decision in general defense plan.

Re-evaluate return if transport moving away too fast.
Could have a "home" unit that is preferred if in range, such as
fighters assigned to carriers.  Don't return to transports that
don't have any fuel, unless there is no other choice.  Special-case
grounding of aircraft if no supply in a base vs starvation of troops
if no food in a base.

Exploration plan should set recon vs invasion type, use to decide
about visibility while exploring.  Recon should attempt to gather
knowledge without being seen.

If can refuel along a route if chosen correctly, subdivide move task
so as to stop at refuel points.

Define a plan type that tracks/shadows units while staying out of sight
as much as possible.  Would have to keep unit within view range but outside
of its view range (and any other coverage, should write something to see
whether a given cell might be visible to enemy), but may have to get
closer to avoid losing trackee.  If unit being tracked seems about to
do some damage, engage instead of shadowing.  May sometimes want to
move to block or slow down trackee's escape.

Need special scenarios to be able to test all plan types accurately,
should set up similar tests for all major parts of planning and AI code,
each should ensure that all the code bits actually get executed.

Plans that fail to decide what to do are a potential problem, should
eventually be replaced, but not too often or else warn about replacement.
Track total usages as well as per-turn usage.
Each successive plan for a unit should have a distinct serial number,
display when displaying plan.  (units never share plans)

All units should get a chance to replan after acp/mp calculated
but before anybody moves.  Should be fast, since nobody can move
while this is happening.
(Interface should be more obvious about this, so less confusion
about turn change.)
Give human players a chance to review plans made by high-initiative units
before irreversibly made (flag review-plans, shows plans of units that
are selected).

What about a task to not just resupply but to prepare for a long trip?
Stock enough to make a crossing, etc.
Check when doing an approach task, may want to push a "fillup" task.

Add notion of "supporting" another unit to doctrine, then unit could wake
up and get involved automatically if combat nearby.
Should specify by type & distance, as well as particular unit.

Do general org chart mechanism.
Allow promoting any (or restricted type?) unit to be a commander, and
assignment of units to commanders.  Cmdrs always move before other units,
units can have orders to follow cmdr, cmdrs could have utype requisitions
so production automatically goes to them.
(Machine player could use this too.)
Add a display to show how everything relates.
Define a commander_decide_plan(cmdr, unit) or have cmdr make tasks directly?
Each commander should have (or appoint) a deputy unit that will get its
plan data if it dies.  If deputy dies, should work down through orgchart
to find anyone, only giving up if entire group is gone.
"Commander" plan is mod of other plan types, cmdr bit is for coordination.
Cmdr plan includes an "ideal" mix of types to command.
AI uses to set production, human gets told of cmdr unit's needs somehow.

If no AI or display on a side, what should units do?
Will still have doctrine, attitudes, loyalties, so plenty to work from
(include indepside in this but have no side-style coordination?)
Can have and execute plans but no mechanism to change plans
(i.e. can be read in but not altered thereafter - would need to flag?)

Should be able to set a "build rate" that is slower than "fast as possible",
to avoid material depletion.  (i.e. use doctrine to set default rate of
build actions, set actual rate in build task?)
Define as amt of time to wait before starting build of next type (if the same).

Define a "meet" task where transport and occ (or whatever pair
or group) converge on a mutually acceptable place.  Track progress,
give up if not getting closer.

If hit/capture task fails because target has disappeared, offensive plan
should search vicinity of target location for units of matching type.
(But might be better to let generic task planning take over instead.)

Goal to move to an area should be satisfied by moving to nearest spot,
instead of a random point inside.

Add an "engineering" plan type, with subtypes "make-access" and "block-access".
Engineering units build access routes
by adding/removing/modifying terrain, or by building units that serve
only as bridges.  Should be able to build multi-cell/unit chains in
difficult cases.  Examples: could bridge one blocking cell by a) building
a transport unit that ferries, or b) building two connections.  Could
bridge a single blocking border by building a connection or by removing
border.  Want to do this for any cell that is very expensive to cross.
To implement, plan should look for cheapest route assuming that blockage
has been negated, then build bridges for that route.
Engineers should also know how to build roads, do that if road movement
is much faster (such as doubled) than normal movement.

Example doctrine for building-type games:
(side-defaults
  (doctrines (u* default-doctrine) (places place-doctrine)))
(doctrine default-doctrine
  (construction-run 1))
(doctrine place-doctrine
  (construction-run (u* 99) ((carrier battleship) 3) (nuke 1)))

--AI

For AIs, define a struct ai_ops (a la gdb) that includes all operations
that AIs must support, call these directly instead of going through
case statements.
Move mplay.h into mplay.c, remove specific <ai>.h files from ai.c,
move mplay.c to ai-mplay.c.
Build (manually) registry of AI types somewhere, let game designs
specify preferred or required types for particular sides.

Don't build transports if there is no way to get them to where they will
be useful.

For each type of goal in game, decide which units help accomplish and how
well, which units support indirectly, etc.  Also classify by short/long term
value - short-term is 5-10 turns or 1/10 of game, long-term is length of game.

Set initial theaters to be identical to initial search zones, gradually modify
to match terrain better.  (Theaters divide down middle of seas, etc.)
Initial search zones should be from center of country in six dirs, subdivided
by distance (increment should be 10, speed of fastest unit, 1/10 of world).
Can use knowledge of country size to optimize search, by spacing out explorers,
not filling in details of terrain until later (is diff, low-priority goal,
maybe subsumed by patrolling).

Fix where town doesn't decide to build - happens when AI is assistant to
display and town wakes up (enemy passing by) but doesn't already have a task.

Add ability to have future goals, ultimately be able to script much
behavior.

Prefer to hit or capture transports, especially if easier way to bag
or destroy the occupants.

Keep a persistent layer of "sightings" (or linked list if can be short),
record into when nonempty cell in view array is about to be cleared
during a turn (need hook from vision code).  Date sightings, clear
periodically.

Neutrals should be run by AI, but act only in self-defense,
other AIs should be aware of this.

Need a way to estimate units hidden in transports, so can freak out
over approaching transports.

Compute desired number of depot types by calculating the spacing
between necessary to ensure that each can supply another.

If only one builder available, should "timeshare" it properly.
Plan should track what has been produced, reduce preferences more and
more of a type gets built.
Test with old-empire.

Add heuristics to try to build bases at key or useful locations.

Hit worth should be the general payoff of one-on-one combat.
First test if combat possible.
bhw = 0 means breakeven.
bhw > 0 means always advantageous, < 0 disadvantageous.
Should account for construction and fuel costs? (is "Strategic worth")
In practice, tactical needs will outweigh the risks involved in fighting
when bhw < 0.
Also account for ability to escape, so less risk?

If scorekeeper body says something about testing possession on a given
turn, then make occupation a goal from the start.
If occupation goal unsatisfied, assign units to occupy, give each
the same goal, should also attempt to clear the area.
If satisfied, assign unit to defend the area (need to write "how
to defend" code?), possibly patrol around if everything not always
visible.

Speed up theater searches with a for_all_theater_hexes(th, x, y),
that iterates between min/max x and y.

If contacted more than one side, choose a side to concentrate on
(closest most likely), act defensively against other sides (but
still take opportunities).  May need to change emphasis if another
side turns out to be most threatening (tell this by tracking apparent
success w.r.t. each side).

Shift from offensive to exploration if everybody disappears.
Should be persistent in covering area near last spotting of units.

When a unit executes its plan, routines like find_target()
either get a value from AI or search around (implicit "nobrains" AI?).
(AI should have prioritized list of targets composed already and
sorted by theater and goal etc.)

If parts of world view not necessarily up-to-date, need to do pickets
or patrols to guarantee as much coverage as possible. (use view dates)

Designer should be able to toggle flags for mplayer,
force reevaluation etc.

If moderate-to-high chance of unit surround, should put units in
lines and other formations that can't be surrounded easily.

A side should act primarily defensively if it satisfies a goal,
but the game is not over and another side could take away.

Guess at likely theater for contacts, carve out of existing theaters,
reassign/replan *all* units.

Track contacts with other sides on a per-theater basis.

Mplayer should compute which types are mostly likely to be in play
at present, and at future times.  Can look at initial setup, construction
times, etc, and ignore types that can't possibly appear.

Mplayer should attempt to compute numbers of units and material needed
to achieve a goal, to some level of confidence, then set "buildup" plans -
some units explore/patrol etc, then when buildup finished, should plan
large-scale attack, from several directions if possible.  Reserve units
should hang around transports, but not sit on them unless transport protected.

Use people sides to adjust theather boundaries sometimes. (how?)

If chance to surrender by siege > 5%, compute an ideal frontage, minimizes
chance of units getting isolated.

Could do formations by reshaping theaters.  Units mass on edge, don't go past
until AI directs an offensive.  If offensive successful, AI adds gains to
theater.

If returning to a moving transport, and transport destination is further away,
push a "wait" or "rendezvous" task onto transport's queue.

Be able to change theater size and shape as the situation changes,
let theater develop to optimal size.

For each theater, distinguish
recent vs older sightings, with exponential backoff (1-2 turns ago,
3-5, 6-10, 11-20, etc).

AI should have a chance_to_own_one_of_type(side, side2, u) that the side's
current estimate of the likelihood of the given side2 owning at least one
unit of the given type.

Very small theaters should evaporate (how to recognize?).

Need special code to know how to defend bridgeheads, recent captures,
etc.  Reduce theater size or focus on immediate vicinity.  Own units
in "enemy" theater (define) should be defended against the most
immediate threats.  Look around for threats or potential threats.
Assign best units to deal with threats.

Need better weighting of hit prob vs death prob, also relate to goals,
so unit with low hit prob will still attack another unit if it can win
the game by doing so.  (implies we need to evaluate importance of goals,
nearness to achieving them)

Have machine player compute general dependency chains for its strategy.
For instance, "need miners to produce uranium from mountains
to build nukes to attack cities".
Should be "lazily" computed, as needed to achieve basic goals.
Strategy code works by calculating a plan that consists of steps
to reach the goals.  Plan is sufficiently detailed when side can
tell each unit what to do, or doctrine has the same effect.
Not always totally deterministic, how does this work?

Unit type analysis should be based on average outcome, plus worst/best-case
outcomes if not maybe not expecting enough action to let things average out.

To estimate materials, scan world, for each unit image, add survival
needs to min est, stockpile - avg operating costs to likely est,
total storage capacity to max est.  Can use actuals for own and allies.
Similar for terrain and population.

Unit first spotting human enemy should disappear as quickly
as possible, might escape before human notices. (exploratory plan only)
Purely exploratory/recon units should generally avoid combat, try to escape
and stay hidden if possible.

Resign if goals (as derived from scorekeepers) are provably unachievable.

Theaters of < 6 cells should be removed entirely.

To decide when to make bases, do if can create supply, can xfer from
further than units can, can protect units in or near base.

Do base construction as 1) moving to construction site, 2) building, and
3) carrying to final site.  (Must verify that base or parts of base can
be carried.)

When exploring and switching theaters, shift both to inner and outer
theater (actually an abutting theater of any sort).

When enemy unit spotted in a zone, decide if unit is part of larger
group (like a country), what kinds of units might be present (similar,
sessile, etc).
If unit is isolated, decide if it is a threat in any way, if so, make
a goal "enemy gone from x,y" and assign units to work on this goal,
with types and numbers sufficient to the job.  Can borrow from nearby
theater if not too time-consuming.
If group, decide importance (home country being most important),
also assign # units, maybe make theater, track strengths, # units
enroute, and # still needed.
Distinguish units that are dangerous alone and ones that are carriers.
An army that is 2 cells away from capturing a self-unit should have
a maximal threat, since loss of game is certain if threat not counteracted.

Machine player should attempt to infer other sides' strategies.
side->strategy->other_side_analysis[nsides]
If no player on other side, record that other side will not do
anything (and go after to build territory).
If has a display, record as "more dangerous", use as a reason to
ally with other AIs in game.
Sides with displays should also be considered "more unpredictable".
If AIs ally, should be temporary, since game won't end even if all
are allied.

Define an "importance" of activities that gets divvied up among
subcommanders, so overall plans can be set aside temporarily while
individuals deal with immediate threats.

Machine player code should look for "choke points" that are standard
routes between important places and around obstacles.  Calculate from
world and utypes, share among all machines (don't use if haven't seen
yet!).

Write a stdplay.c that is only applicable if game is similar to standard
game (examine set of types, but still need to doublecheck numbers).
Share lower-level routines with mplay.c.

Eventually add code to negotiate for neutrality/ally status.

Add a player slot that can be used to set explicit AI goals, would
take precedence over computed goals.

Mplayer should be make goal forest instead of just a list.

Mplayer should prefer goals with fewest dependencies (prereqs) and
quickest time to completion.  Prereqs mean conditions that must be
true before main goal is worthwhile attempting, but are not formal
requirements - goals are intrinsically self-contained.

Get goals from a hash table instead of creating anew each time.
Parameters of goal will be read-only.
get_goal(type, p1, ...)
change_goal(goal, newtype, newp1, ...)

Scorekeeper analysis:
if keeping score
  make overall goal to win
  call make_subgoals
else amuse self by being random
if goal is to win
  for each scorekeeper
    if last-side-wins, ... (already done)
    else scan body looking for if's and do's
    (might be too complicated, should announce the fact as a warning
    "too complicated for me, don't know how to play" and drop
    back to simpler if mistaken goals)
    if body is "(if <test> win/lose)"
      make the satisfaction of the test a goal
if goal is to make a side lose
  if can be accomplished by eliminating a side's nonzero-value units,
  set goals to destroy/capture each type
  if not all visible, set goal to find units
    if type can move, goal is to keep info about world up-to-date;
      no random walking, always move to update oldest spots (but
      only in terrain where units could be)
    if type can't move, goal is to have examined all possible
      terrain.

--Interface

To choose contour interval for elevation display, get actual elev range
and subdivide into equal intervals, or define a "standard interval"
and multiply if would result in too many lines on map (> 1 line between
cell centers is too much).

Generalize X11 machinery for controlling mplayers hogging all cpu time
and moving too quickly.  Characterize as *interval* between calls, so
mplayers act more slowly if more calculation required for each move.

Add an imf procedure to compute actual bbox of nonzero bits/mask in an image.

Nightfall should update cells from the top down.

When drawing elevation changes, draw a gray line at cell edges to indicate
the "crease".

To indicate slope, draw center of cell with shape for next smaller mag,
then sloping rects joining adjacent edges of cells, then triangles around
each 3-way meet (for hexes anyway) to fill in holes.

Should not be able to appear to attack if attack not allowed
(arty in ww2-bn for example).

Compare 5.5.1 commands, tweak standard commands to match if reasonable.

Add designer save option to write only some props of a unit, such as
position, and write as (unit <id> <props>), using name, number or id
as identifier.

Use generic names when summarizing types at a location or in a transport.

Add a side->ready_to_start that each player must enable before actual
game play starts.  Initially false for all sides, mplayer sets when
init done, interfaces enable at player's direction.  Could be button
or implicit when player tries to move.  Note that if multiple humans, and
one tries to move, move will not actually happen until everybody either
tries to move or else clicks on the start button.

Define special-terrain-images, allow values like
(beach (terrain (ne sea) (half (n sea) (s beach)))
       (border (w nw) river)
       "beach&sea&river-1")

When "view" of cell becomes an "exact view", do an update of it.

Interface should indicate a "move near" plan with a multiple lines
indicating radius.

Redraw cells even when coverage becomes zero?

Standardize image names more:
[<game>-]<picture>[-<era>]
[<game>-]<function>[-<size>][-<era>][-<side/individual>]

Add "angle" and "facing" properties to images, and "dirmask" for
linears.  What about combined ttypes (beach + sea, etc)?

UI data save should have format
(ui-data <generic-props> (mac ...) (xlib ...) ...).
Use {read,write}_generic_ui_data(fp, side) that does generic stuff, and
calls to {read,write}_ui_data to do interface-specific bits.
Copy other interfaces' data through, but don't mess with.

Direction chars in dir of blocking terrain but adj to a slideable
border should cause a border slide.

Linear terrain should be affected by night - draw half-black mask.

Command "ai" toggles between default aitype and none, while "ai <name>"
switches to particular ai type.

Add ability to switch to alternate color/icon schemes, such as
winter camouflage for panzer, or military vs pictorial icons.

Add mechanism so that messages get echoed back, for confirmation
of contents mainly.

Fix interfaces so that only one base gets ordered to be built, but lots
of infantry from cities.  (in doctrine, feed to interface? - needs to
be part of default doctrine for all sides in a game!)
For standard, do
(side-defaults (doctrines (u* default-doctrine) ((* @) city-doctrine)))
(doctrine default-doctrine (construction-run (u* 1)))
(doctrine city-doctrine (construction-run (u* 99) (nuke 1)))

When displaying perspective, show top and bottom of "thick" terrain.

If command arg spec is just "*", then make all command args into
a single string, passed directly to command.

For textual commands, interpret <tab>, extend words, etc.

Detect image and image family conflicts/overrides when interpreting imf files,
warn about unless suppressed.

Handle some glimpses as special event types, such as spotting occupants
in a unit, instead of trying to draw on display somehow.
Call glimpse_unit(side, unit).

Don't say, for instance, "independent 2nd wreck" in textual displays,
but just "wreck" - both in topline displays and narratives.

A game design should be able to specify a per-side optimal centering
for the initial view.

Add some kind of sort key control to help info for commands.

Add more help nodes to explain general concepts like acp.
Describe each general concept that is enabled for the given
game, otherwise say "no xxx in this game".

End-of-game stats should use own system for double-entry bookkeeping.
(should display discrepancies only if nonzero)

Add generic commands to go up and down ('^', 'v' perhaps)
How should they be interpreted?

Allow definitions of images that constitute the border between two given
ttypes, or t1/t2/border combos, etc.

Add image properties that indicates approximate orientation and
direction being viewed from (side, top, 30 degrees, etc).

Draw some features by using boundaries, of different appearances.

Need a way to indicate relative precedence of sort keys in list windows.

When in mono, allow choice of small numbers or letters for side, instead of
emblem.

At high mag powers, draw people emblems near borders of hex instead of in
middle.  (when emblem width < 1/4 cell width)

Define a -h <n> that sets up and waits to get pings from human players.
Like -e <n>.  Kernel only has "wait for <n> remote players", cmdline
does the -h part. -wait <mins> to say how long to wait before going
ahead, also allows players to get impatient and start anyway.
Ideally, the startup host gets a window or command interface
to control the startup process, see who is in, perhaps edit
display specs.
All player specs should be able to add "+n" to adjust advantages,
as in -e 4+2, +2 alone (one mplayer, +2 advantage?)

Players should be able to join above by doing "xconq -join host nnnn [-help]".
Help shows description of game and list of players/sides; say "(available)"
if side is waiting for a player, ask terminal for a side number to join in on.
Serving game must open a socket to listen.  If under X11, program can quit
once display is open; for others, program will continue to run.

Define some common part of imf reading and interpretation in kernel
or a common support lib, extend basic image structs with interface-specific
detail:
    struct imf { common com; specific icon,... }
Common includes size ranges and maybe depths.

Some images in imf may be precalced for a hex or other shape,
need to indicate specially.

Game should be able to spec relative or absolute widths of borders
and connections (used when solid or a pattern).

If multiple conn/bord types, interfaces should draw them offset slightly from each
other.

Should be able to, from cmdline, list available player slots in a remote
game without actually trying to get in.

(is sort of done now)
Allow adding a hole or mask to add side emblem to units (plus offset?).
Specify as (image ... (emblem-space x y w h) ...)
Also, each image can declare that an emblem is already embedded, as
... (has-emblem <emblem-name>)... (would still draw actual emblem if
it didn't match the embedded one - leave embedded one, may be useful info)

Should be able to parse dates in commands,
omit parts that are same as current value (such as year).
Date string function should cache stuff, so not always allocing new
strings.
Length of a turn specified as "<n> <unit>" where <unit>
is known to calendar type.
Robustify the base date parsing.

Add a text parser etc for specifying units and types.  parse_[urt]type,
parse_unit should be able to recognize ambiguous matches, either return
# results or report of multiple, be able to process each independently,
put in dialog, etc.  parse_feature to locate geo geatures by name.

Need keywords for images to tie less specific images at smaller
scales to more detailed ones - "su-85" -> "tank", etc.

Kernel should deliver basic formatting info in help text, let interface
digest - need line breaks, text fill, tabs/tabstops, emphasis/bold (use
^B,^P,^I chars?).  Perhaps some way to name a picture and let interface
fill in actual picture.

Do something in general for reporting destinations, choices are
raw coords, dir/dist, or a dest name of some sort (unit or region).
Useful to have optional map scale to report distances in miles etc?
Examples: "in xxx country" (needs defn of country)
(define gvar "start-area-name" that gives name?)
"NE of country" "E of Foo Bar" "in <region>"
Function is position_desc(buf, side, x, y), where side==NULL means
do for omniscient side,.
also define position_desc_relative(buf, side, x, y, x2, y2).

If info is always accurate and up-to-date, calculate display directly
from state.  If might be unknown at first, but always accurately
known once discovered, keep a bit/piece of info, display from state
if bit is on, else show nothing.  Similarly for info that might
get out of date if observer not present?
If info might be known/unknown and right or wrong, then must maintain
full copy, though can forward to real state if internally known to be
accurate.

Add imf property for additional info about an image. (explanation/derivation,
aimed more at game designers).

Add option to draw contour lines for elevations.
Contour intervals should be based on range of actual elevs, but let
player adjust (perhaps by looking at histogram of elevs).
Game design specifies color of contour lines.
Draw for each of six triangles P0P1P2 in a hex.
Pick two corners with elevs e0 and e1.
For each contour elev ec between e0 and e1
  If e2 > e1, no contours go to the e1e2 side
  If ec between e1, e2
    Draw line to e1e2 interpolation of ec
  If ec between e0, e2
    Draw line to e0e2 interpolation of ec
End
For each contour ec between e0 and e2
  If ec between e0,e1
    Draw line to e0e1 interpolation

Add designer tool to paint theaters for AIs.

In perspective view, displace units by both elevation of cell and their
altitude above it, maybe draw shadow on ground if airborne.
Center unit in cell better (?).
Shade slopes in perspective view according to time of day.

To support multiple natural languages, associate one of several languages
with each side, use to invoke nl-specific nlang.c/help.c routines.
Also have separate command definitions (de-cmd.def, fr-cmd.def, etc)
that interface should be able to use instead.  Each interface, if configured
for it, will have to set up all the command tables, so can be chosen
by each side at game startup.

Document that Unix-hosted versions must provide void close_displays()
so that signal handlers may call.

Add interface-independent printable display of all help info.

In printed map, make grid be gray, draw only around known-about terrain.
Draw area edge in light gray if adj cells not known terrain.
Use halftones or patterns instead of bitmaps possibly, add a
color -> grayscal translation process.
General cmd should be "print [window] [width]", where saying "window"
limits to contents of a window (else whole area is printed), and width
gives physical width of map, default is to fit on one page.
Each page should include a legend showing terrain, units, sides, use
up to four columns at bottom of page, run types together in columns to
save space. (Ditto for text/ascii view.)

Common printing code handles layout setup, layout checking, and actual
computation of printed view.  Interface handles any print setup dialog,
plus final disposal of printed view (to file, to print queue, etc).

At end of a turn, display summary/histogram of action/task/plan types
and outcomes. (debugging display?)

Need a general (all-interface) strategy for guaranteeing image
consistency on screen.

Add ability to select direction of perspective view.
Easier if only one of NUMDIRS dirs allowed.

Clarify rules of how immobile units get on transports.

When autoscrolling, interfaces should support a brief delay option so that players can
see the outcome of a unit's last move for the turn.  Can omit if next unit is close by
and no scrolling was needed.

Add ability to supply phrases for table row display in help:
"[can create] by default, [except for] base,town,city".

--Coding

Write a generic interpolate_in_list(val, lis) that computes a value using
the value pairs in the list, use for all things that are a list of pairs.

Implement "may-see-all" and "see-all" as a side flag in kernel, use instead
of g_see_all everywhere.

In lisp.c, be smarter about ptrs to line numbers passed into reader,
do nothing if they're NULL.

Make gamestatesafe, interfacestatesafe visible everywhere.

Loop through vardefns[] to write out globals instead of including
gvar.def and expanding into separate code for each.

PS printing (should?) require ui.c and imf.c.  Include a configure option to add/remove
PS printing code.

Put some/all info subwin text gen into ui.c or nlang.c, as appropriate.
unit_or_view_info(side, x, y, unit)
cell_info(side, x, y)

unit->side != indepside, always!  (how to check?)

Add a side->allow_entry[s][u1][u2] that says allowability of unit entry
into transports (use for indepside also).  Seed with 1 for all pairs
of types if side is trusted.

When recalculating coverage, detect discrepancies, warn about?

Write goals as separate forms, make xrefs to them.

Record the global state when becoming a designer, be able to write out
deltas only.
Be able to select only particular properties + unit id to write out.

Eliminate USE_CONSOLE from kernel, decide with a runtime flag.

unit_desig should format typename into minimum space, determined dynamically.
Assign chars, if defined, as shortest names, then add longer names to
uniquify names after the first using a particular char.

In theater summary, don't print "people" if no people of any type are
present.

Allow multiple -L specs for libraries, support list of library dirs to search
for a module.

Collect/write stats on each call to run_game - # unit scanned, # acted,
# actions, # plan executions.  Also classify by type and side.

In initial game analysis, calc which utypes can be on which sides,
stash with side info.  For AIs, also stash guess about first turn
of appearance?

For each scorekeeper, add an internal flag that saves applicability
of scorekeeper, also calc for current turn - if changed, then AI
analysis code should re-run.

Write a search_straight_line(x0, y0, x1, y1, fn) that scans
exact line between places.  Could also do 3d version.

Be able to save individual properties along with ids to match with units.

Add option to save a map rotated, at least by 60-deg increments.
60 left, 1st hextant formula is y' = x + y, x' = -y, etc.

When lots of mallocs being recorded, either maint enough space to
record all, or else drop/combine smaller totals to make room to
record the big allocs.

Write dice specs as dice specs, not large numbers.

Use 16-bit indices to an array of pointers to units.

Add a kernel routine notify_all that goes to all players with displays,
requires ack from all, support voting and timeouts.
Use in x/xt version for run errors etc.
(is this really useful?? could be a general multi-player alert
with voting/ack requirements)
multi_alert(msg, sides, [minquorum, mintopass], timeout)
multi_query
update_multi_query_display
interface calls ack_multi_query

Define zz-s-u-n as cache for shortest name (down to 1 char if possible,
but confusing if only some have one-char names, others are all-but-one
char of name, etc)

Define a can_occupy(...,exclunit) that indicates room if given other
unit is *not* counted (since it will be removed shortly, for instance)

Make a bit vector of allowed sides for each type.

Define performance as a sort of ratio to specmarks, so benchmark game is
known to last 2 minutes on a 100-specmark machine, etc.  Use -R 1, only
"real" games, various mixes of AI, little/no interaction.
Games should include classic, standard, gettysburg, magnusvew, ww2-eur-42.

Doctrine consists of a list of modifications to a single doctrine object
that is final answer (no doctrine relationsships).  Can always clone a
doctrine but then is severed from original.

Add general check on parameter bounds as given in *.def.

Define foo_text(buf, n, xxx) where n is available space for description,
return actual length of text in buffer.
To get strings, define foo_string(xxx), which returns a 0-terminated string.

For all units on a side, keep sorted by type, keep ptrs to start of each
type, use to index faster.  Could even maintain separate chains for each type.
Define a for_all_side_units_of_type(side,type,unitvar) iterator.

Implement a convex region finder that works by picking random points as seeds
and grows out from those.  Sides have to be "locked" if entire side can't
all grow - combo of locked and unlocked sides allows region to become
parallelogram, triangle, etc.
How should borders and connections affect generic region finding?
Grow from random points until about 3/4 of cells in regions, then scan
down to finish off.  (Could leave single points as "their own regions",
not alloc any region structs.)

General path objects consist of multiple segments, each with start/end
point and a validity test (that can be done at any time).  Also include
a bit with segment saying "shortest" or just "nonincreasing distance".
Should be possible for a path to say "impossible" for some segment??
(consider path that consists of land travel segments plus a sea hop
that needs a ferry of some sort - path is still valid and useful.)

Regions should
point to super-regions, not necessarily contained.  Include bits for
caching connectedness, terrain percentages, etc.  Add region layer to
regular map (each hex can only point to one region, multi-stuff must be
between regions).  Need commands to define and display regions.
Regions never overlap, must subdivide and make subregions be included
in several super-regions.  True for all regions, don't do multiple
"region layers" (unless significantly more efficient?  check stats).
Add region layer for mplayers that need to explore, add to layer
as mplayer sees stuff.

Theory of networked Xconq is that all copies synchronize on actions
and random seeds, then do run_game and get identical results.  Each
program will broadcast its planned actions, then wait until each other
program indicates that it has sent all that it plans to.  When a program
has received "done" from all others, then it can safely execute.

Allow various combinations of multiple- and single-server games.

For any routine in the interface that tweaks in the kernel, have to
siphon it off to the network also.  Do via compiling interface with
augmented calls, so kernel code need not be modified to know about
networking.  On receiving side, input mux includes a decoder that
invokes kernel routines (note that decoder has to know about calls
that not all interfaces actually support, since less-powerful
interface may get kernel-changing messages from more powerful interface).

Build a "skelclient" from skelconq.c and client.c.  client.c includes
a "wait_for_server" that calls run_game or just accepts outcomes and
state changes from the server.

Come up with a way to prove that mplayer doesn't cheat by looking
at structs?  Could have a have a "sneaker" that is always invisible,
never attacked unless mplayer cheats.

Add tests involving two communicating skelconqs with preset port
numbers, use to test networking behavior.  Use a skelconq and Xconq
on Macs to test PPC (or GUSI?)

Add a protocol version number etc so that mismatched versions can't
connect.

Further compress layers by including info about # bits (1,8,16).

Define a "text buffer" object that is variable-size, resizes as needed,
do all printfs into it.
To guarantee integrity, program could display checksum or signature to players
upon startup, so they can agree as to identity of program.

To do play-by-mail games, need to be able to save an optionally encrypted game
and pass along to next player -
player info includes some sort of bit indicating
where to send to. (player-address slot)
Encrypted game should retain game-module form as plaintext,
include a "password" slot, then all numbers appearing at "top level" will be
decrypted, random forms still read normally.

Optimize mapping side and unit ids back to objects themselves.  Use hash
table for units, direct table for sides.

For tables, merge index1,index2 slots into one char(?) slot.
Make keyword value a char.
Set up table(type?)s in dynalloc space, sort for efficiency in search.

When saving elevations, always save as 0-based + addend values, doing
multiplier less important.

Use obstacks for building up help text.

Finish writing game compiler, test, collect speed comparisons.

Historical events should always be unique; check for duplications and
complain or avoid creating when restoring a game.

--Documentation

Infoize manual, improve online appearance.

Remove mentions of u_storage, t_storage in document?

Document that acp-per-turn and ...-min both default to 0.

Document that acp-per-turn-max defaults to -1, which means acp-per-turn limit.

In hacking.texi, doc that language can't change if *.def untouched.

Add html-ization for manual.

Describe parameters of actions.

Build syntax.texi by replacing <unit-type-property> with actual list of
names extracted from utype.def.

--Testing

Write tests for resignation, draw, win, lose situations.

Add testing machinery for the graphical interfaces.
Could have AIs play each other on multiple screens.

Add a (quit [if-end]) command to skelconq that exits.  With if-end,
only exits if at end-of-game.

Instead of scanning lib dirs wholesale, make up a list of combinations
of game and variant options to run.

test-lib should run all the useful -g options (use game.dir to collect).
Then run a script to discover which modules are never
loaded by any library game.

test-lib-modules should just load each module then quit - looks for
immediate crashes due to player error.

Set up basic "make check" to run limited tests on library and standard
test cases, when defined.

Set "make ai-check" to run long AI tests.

Add more directed tests as DejaGnu tests.

For running tests, use explicit -L to lib and test dirs.

Finish adding test images to test.imf.

Add tests for end-of-game handling.
Set up some lib games with non- or feeble sides, so one side wins
more quickly, plus heavily lopsided advantages.

Add save/restore tests, require that diffs of successive save/restores
are either empty or of a known format (assume calls to run_game can be
controlled by skelconq).
To test save/restore of tables, dump out help info separately and
compare after restoration.
Also use compiler and compare its output.

Add a test of external synth program.

Add a source-scanning test to find possible calls to rand() or random().

Reflect GDL changes in all.g, add a scanning test to ensure that is
consistent.  Run all these automatically as part of "make gdl-check".

--Library

Set standards for names of library files:
case-insensitive, hyphen/underscore equiv, max of 11 chars for
name, 8 chars unique (algo - remove hyphens/underscores, then vowels),
3 chars after dot.  Write a name analyzer/checker, DOS code should
do name reduction algo when trying to open a long name file.
game.dir -> game_dir. for DOS.

Recognize "color" images that are really just B/W, read/write as B/W.
(mac only??)

For X11, make imf2x/x2imf translate bitmap filenames and struct names
properly.

WWII scenario should be able to have a "neutrals" side that resists
involvement.  Attempts to attack neutrals should have some consequences.
Spain and Turkey should be neutral, but if attacked, will go over to
other side.  (This should be recorded in the scenario as a preset
property of those AIs!)  AIs on opposed sides should assess value
of capturing side's units vs expense & risk of combat.

For napoleon, make all cities visible, view all units once/month,
but don't be see-all.  Unit positions can be kept more up-to-date
by spies, or say that all units can spy out to 4-5 cells and all
cities are always spotted - so movements around and through are
always known about.

Add more 16x16 panzer images.
Eliminate slope terrain, replace with hilly or rough.

Gettysburg brigades should vary in quality and hp.

In pelops, try to model Athenian grain trade (abstractly or concretely?)
Constrain eastmed map to about sicily-sardis, lissus-crete area.

Change stdunit so that only towns and cities count, not armies?  Will
require better defensive operations.

If fighters had a low land/takeoff time, then could attack adj bombers
a lot more than now (realistic), but bombers can't escape then, unless
some sort of generic auto-retreat implemented (a good idea).  Auto-retreat
might happen in addition to the hit, rather than instead of the hit.
Refuel should consume part of flying time, but not all, then can
fly many sorties against nearby targets.

Skelconq should examine lib.imf directly during setup, report
on which images were found for the game being loaded.
(Not error, because interfaces not required to use image library.)

Collect all old games, do partial translations.

Image tools should be able to study colors and colorized images
usefully somehow.

Let images refer to colors by name.

Make new world maps that use connections for straits and rivers.
Distinguish navigable/unnavigable rivers?
(extra layers should be optional - could do "ifdef river type")

Add notion of named palettes to .imf files, in form
(palette name color1 color2 ...)
then images can refer to palette by name and colors by index.

Modify standard game to be more resource-bound, supply used up
faster, all units must be kept supplied, need to build strings of
bases to get supplies out to where needed.

Write a ww2-std-pac-42 scenario with Allies (including Soviets?)
vs Japan.  Immediate post-Pearl.

Change ww2-div-pac to include diff sizes of ground units (reg, bde,
marine bn, inf-bn, marine-div).

In ww2-std-eur-42, add Suez as base, make Mecca be a base, mention in
notes that Egyptian cities represent ME/Africa/India supply sources.

In ww2-eur-42,
Swiss, Spain&Turkey should be inaccessible, also remove any indep cities.
Sweden inaccessible?  Add 3-5 rows to top of map.
More US cities for balance, more depth to USSR (move existing cities west).

WWII strategic games should have large number of predefined agreements
constraining players.  Add more pre-existing units to all sides.
Fleets should take longer to build?
Add "Axis/Allied minor" sides that include Balkans, etc.

Capturing city in advanced ww2 should cause immediate side change
in cell.
Add handling of oil as resource - inf needs little, armor needs lots,
but only to move.

Add night option to panzer, add area illumination so that wrecks
can illuminate immediate area.

For Normandy, set up staging areas for German reinforcements to arrive from.
Set German AI to be primarily defensive.

In flattop, gen names like "LC-1", "CA1", etc.
Allow stacking of ships - 4/cell.
Let subs be in same cell as enemy surface ships, let dd's attack there.

--Game Ideas

"Quest"

For one player usually, starts out as a vagabond with limited materials.
Either convert self to higher "rank", or else have improved capability
via experience points and more equipment (but what would "equipment" be
good for exactly?).
Can capture other humans, animals, etc, use as assistants of variable
loyalty.
Terrain is standard.  Include rivers and roads, with significant effects.
Units would be various cities/towns/villages, usual (wandering?) monsters.
Could have a machine-run side that seeks to capture/kill player, like a
police force or army (or assassins?).
Have ships for crossing oceans (but need to "buy" somehow, and if in town,
town should be on coast).
Include weather/seasons with significant effects.
Need unit/material as object of quest, perhaps different kinds for
different games.

(Need to be able to enter/leave neutral places without capturing, but also
be able to accept surrender - perhaps a notion of "if a place is indifferent
to your existence, can interact without combat".  Extend to hostile places
that you can sneak in and out of, though at some risk.)

Should predefine all sides(?), but allow multiple adventurers and only one
monster side - lock this side so players can't take it (but not always?)

To make a game of graduated difficulty, make a long horizontal world, put
player at one end, goal at other, lots of monsters in middle,
tougher ones further away.  (Monsters should move around a little,
but not overwhelm player instantly - could make "electric fences" of
ttypes crossable by player but not monsters, so even fast monsters confined.)
Would look like a string of sausages - 1600x40 world is approx equiv to
40-level dungeon.
Won't be computed incrementally though, but could schedule creation
of high-level monsters to be later in game, make a snowball effect where player
faces huge numbers of monsters if too slow at first.

To make a race game out of this, make a star shape with players at end points
and goal in middle.

"Medieval Diplomacy" a la Kingmaker

Each player is a lord/lady with coat of arms.
Few battles, much maneuvering.
More alliance machinery?
Need rules/state for varying degrees/types of alliance, could affect
mutual transport, control, temporary vs permanent gift, etc.
Can move armies around, raise/lower taxes, manage rebellions, wheel/deal.
Players have a chance of dying accidentally or of old age.
Can players be taken prisoner themselves and try to buy their freedom?
(Because if player is killed, possessions revert to neutral or to ally
rather than being acquired by capturer.)

(Need primitive for "exchange", theory is that actual individuals arranging
trade can prevent cheating on the spot, perhaps include a "chance of cheating
success" plus "attempt-to-cheat-p" that each player can set.)

(Be able to have "materials" like age or heat or poison that are deadly if you
accumulate too much? would need a excess-death-chance that is like starvation)

"Modern War"

Develop modern-day military games, both operational and strategic.

"Today"

An all-out simulation of the modern world at a 1/2 degree scale,
with each indep country as a side!  Use earth-50km map,
add cities and population to account for everybody.
Would need high-density cities, factories, etc.  Don't worry about size of
game, use it as a test of massive scale.

"Space Empires"

Like Spaceword HO or GB, based on thinly scattered solar systems with
planets as occupants, ships/cities occs of planets.  Deep space move
very slow (but not less than 1 hex/turn?), but could enter/leave gate
units more quickly if entry of non-adj unit allowed.
Solar systems are always-seen, but would need to explore planets more
carefully (planetary surfaces not plausible tho).
1-month turns??

"Corporations"

[could make a game based on corporations that have units that are
factories etc, should be able to buy and sell them]

[most elaborate might be to allow corporations to coexist with
countries (what does that mean?)]

"Mars"

Settlement of Mars, a la the Kim Stanley Robinson book "Red Mars".
Build underground and domed cities, develop mining etc, try to
control as much of Mars as possible if multiple players.

--Misc

Add a "last-alliance-wins" scorekeeper, use with some games.

Add option to rotate layer data when saving.

Should be able to specify a rotation when saving a layer.

Decide when sides should be able to look at other units' hp.

Decide if/how country growth and initial strength should interact.

For small-part-of-world areas, define daylight-zone and twilight-zone(?),
which default to 1/2 and 1/12 respectively.

Be able to expand country borders by building or occupying outside original
country.
ut_add_people_chance n%
ut_add_people_adj_chance n%

To decide about revolt, define:
u_[indep_]revolt_chance .01n%
uu_[indep_]surrender-chance .01n%
uu_surrender_range n

Only certain types of units should be able to have mixed feelings, alloc
loyalty objects for these.  Loyalty objects all consistent size, needed only
if more than two feelings possible, else use 4-byte slot for values.
u_max_loyalties, default of 0 means like a machine, no issue of loyalty.
1 means always loyal to overt side, but degree can vary.
2 means overt and "true" side, be able to do with no extra space.
>2 possible, needs alloc.  Count indeps as one of sides.

Define a "process" object:
(process <name>
  (agents <unit-type(s)>)
  (automated-rate n1)
  (manual-rate n2) ; + acp to do?
  (inputs <material-types>)
  (outputs ...)
  (catalysts ...)
  (terrain-effects ...)
  )
Process agent units are optional.
May want to add "tooling" of units to do a process.

Restrict Lisp syntax knowledge to small part of code, allow translation
to other syntaxes (tcl?).

Implement delayed views, where a unit that is out of contact with the side
keeps own view data and only merges when in contact with side again.

Add a type of random event where a side or group of units can change
to an active side all at once, reflects changing politics, requires
maintenance of reserves, etc.

To do patrolling/picketing, space units so that few or no holes in coverage.
In theater being covered, check view dates and send units to update oldest
information - should be closest unit or one assigned to cover.  Could therefore
have a patrolling unit that only moves very little since its view range covers
nearly entire assigned area.  Allowable age of views depends on what sort of
surveillance is avail, how many units are assigned.

Derive acceptable risks from goals - unit that is crucial to game should not
risk self, disposable types can be sacrificed.

Construction calculations should prefer multi-purpose units, but randomize if
values close together.  (Test by making game variants with ultra-powerful
units, should see mplayer shift to building all the time.)
Each goal should be characterized timewise, so mplayer can start builds and
have units ready when goal becomes relevant.

Add a per-side flag that indicates if side is willing to have game saved;
voting is similar to that for quitting.

[vision-terrain-effect to alter range depending on terrain?]

[check validity of random event list after loading]

/* (eventually allow part of log to be kept on disk instead of in memory) */
/* (log file should be appended to, name should be tweakable) */
/* (log all relationship changes (need formal actions for these?)) */
/* (summarize some event types rather than recording each, need to designate
   duration of summarizing behavior) */
/* (a game design should be able to control size/complexity of log) */
/* (full data can go back <n> turns, then summarize data further back) */

/* (doctrine or general prefs specify what sorts of events get presented
   to players) */

Implement Massimo's proposal for morale and feelings:

@section Morale and feelings

@subsection Notes

[@code{feelings} and @code{morale} should be kept orthogonal to
@code{cxp} and acp-debt.]

@code{feelings} (towards each side) are ``affinities''; they can be used
to implement ``loyalty'', ``fear'', etc.

@code{morale} is a sort of ``self-feeling''; it can implement
``heroism'', ``honor'', etc.

@code{feelings} and @code{morale} can also be used to model ``magic
spells'', ``bribes'', ``leadership'', etc.

[remove @code{attitudes-max}, have a feeling towards each side.]

[I think that the following ``status'', ``effects'', and ``charm'' parts
are reasonable; the ``change'' parts are very cumbersome, but I couldn't
come out with something better.]

@subsection Status

@deffn UnitProperty @code{feelings} side-value-list@dots{}
The unit's true feelings towards each side,
including its own side.
Defaults to @code{0} for each side.
@end deffn

@deffn UnitProperty @code{morale} fp
The unit's true morale.
Defaults to @code{0}.
@end deffn

@deffn UnitTypeProperty @code{feeling-max} fp
Sets the range for @code{feelings} and @code{morale} from
@code{-feeling-max} to @code{+feeling-max}.
Defaults to @code{0}, which disables @code{feelings} and @code{morale}.
@end deffn

@subsection Morale effects

All the following modifier add to the given quantity; they are
proportional to @code{morale} and are given at @code{feeling-max}
(i.e., they are multiplied by @code{morale}/@code{feeling-max} first).
They all default to @code{0}.

@deffn Table @code{surrender-chance-morale-modifier} u1 u2 -> n%
[use for sieges?]
@end deffn

@deffn Table @code{base-production-modifier} u m -> n
@end deffn

@deffn UnitTypeProperty @code{acp-per-turn-modifier} acp
@end deffn

@deffn UnitTypeProperty @code{disband-chance-modifier} n%
@end deffn

@code{disband-chance-modifier} requires of course the introduction of
@deffn UnitTypeProperty @code{disband-chance} n%
This is the chance for the unit to disband spontaneously.
Defaults to @code{0}.
@end deffn
Example: setting @code{disband-chance} to @code{0} and
@code{disband-chance-modifier} negative can model samurais: when morale
becomes negative (their honor is spoiled), they have a chance of
disbanding (with @code{disband-message} @code{"commits seppuku"}).

@subsection Feelings effects

All the following modifier add to the given quantity; they are
proportional to @code{feelings} towards the ``other unit's side'' (which
may often be the ``unit's own side'') and are given at @code{feeling-max}.
They all default to @code{0}.

@deffn Table @code{surrender-chance-feeling-modifier} u1 u2 -> n
[use for sieges?]
@end deffn

@deffn Table @code{capture-chance-modifier} u1 u2 -> n
@end deffn

@deffn Table @code{withdraw-chance-modifier} u1 u2 -> n
@end deffn

@deffn Table @code{control-chance-modifier} u1 u2 -> n
@end deffn

@deffn UnitTypeProperty @code{revolt-chance-modifier} n%
(proportional to @code{feelings} towards the ``unit's own side'').
@end deffn

@subsection Morale at creation

Builders may ``transfer'' their morale/feelings to created units.


@deffn Table @code{creation-feelings} u1 u2 -> n
Newly created units start with @code{feelings} equal to n/100 of
creator's @code{feelings}. Defaults to @code{0}.
@end deffn

@deffn Table @code{creation-morale} u1 u2 -> n
Newly created units start with @code{morale} equal to n/100 of creator's
@code{morale}. Defaults to @code{0}.
@end deffn

@subsection Morale changes

They all add to the unit's @code{morale}.
They all default to @code{0}.

@deffn Table @code{terrain-morale} u t -> fp
fp is added after each turn to the @code{morale} of u sitting in t.
Models (dis)-comfort of unit in given terrain.
@end deffn

@deffn UnitTypeProperty @code{acp-low-point} acp
@end deffn
@deffn UnitTypeProperty @code{acp-low-morale} fp
@end deffn
@deffn UnitTypeProperty @code{acp-high-point} acp
@end deffn
@deffn UnitTypeProperty @code{acp-high-morale} fp
If u is left with less then @code{acp-low-point} acp at the end of a
turn, @code{acp-low-morale} is added to its @code{morale}.
If u is left with more then @code{acp-high-point} acp at the end of a
turn, @code{acp-high-morale} is added to its @code{morale}.

They model fatigue/rest effects.
@end deffn

@deffn Table @code{mp-low-point} u m -> mp
@end deffn
@deffn Table @code{mp-low-morale} u m -> fp
@end deffn
@deffn Table @code{mp-high-point} u m -> mp
@end deffn
@deffn Table @code{mp-high-morale} u m -> fp
If u is left with less then @code{mp-low-point} of m at the end of a
turn, @code{mp-low-morale} is added to its @code{morale}.
If u is left with more then @code{mp-high-point} of m at the end of a
turn, @code{mp-high-morale} is added to its @code{morale}.

They model starvation/abundance effects. [use for sieges? m is
@code{"food"}]
@end deffn

@subsection Feelings changes
They all add to the unit's @code{feelings} towards the ``other unit's
side''.  They all default to @code{0}.

@deffn Table @code{transport-feelings} u1 u2 -> fp
fp is added after each turn to the @code{feelings} of u1, enjoing the
ride or the vacation in u2 (which can be a ``resort hotel'').
@end deffn

@deffn Table @code{material-transfer-feelings} u m -> fp
fp is added (for each mp transferred) to the @code{feelings} towards the
side transferring the material m to u.
Models pay, bribes ... (m is often @code{"gold"}).
@end deffn

@subsection Morale and feelings changes

They add to the unit's @code{morale}, to @code{feelings} towards the
``unit's own side'', or to  @code{feelings} towards the ``other unit's
side'', according to their keyword.  They all default to @code{0}.


@deffn Table @code{win-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{win-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{win-other-feeling} u1 u2 -> fp
They are applied when u1 destroys u2.
@end deffn

@deffn Table @code{hit-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{hit-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{hit-other-feeling} u1 u2 -> fp
They are applied when u1 hits u2.
@end deffn

@deffn Table @code{wound-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{wound-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{wound-other-feeling} u1 u2 -> fp
They are applied when u1 is hit by u2.
@end deffn

@deffn Table @code{see-enemy-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{see-enemy-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{see-enemy-other-feeling} u1 u2 -> fp
They are applied when u1 sees a hostile unit of type u2.
@end deffn

@deffn Table @code{see-friend-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{see-friend-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{see-friend-other-feeling} u1 u2 -> fp
They are applied when u1 sees a friendly unit of type u2.

@code{see-enemy} and @code{see-friend} can be used to implement
specialized morale/feeling (anti-)boosters: secret police, preachers,
leaders, dragons, nazguls...
@end deffn

@deffn Table @code{capture-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{capture-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{capture-other-feeling} u1 u2 -> fp
They are applied when u1 is captured by u2.
@end deffn

@deffn UnitTypeProperty @code{change-side-morale} fp
@end deffn
@deffn UnitTypeProperty @code{change-side-own-feeling} fp
@end deffn
@deffn UnitTypeProperty @code{change-side-other-feeling} fp
They are applied when u changes side (own is the ``old'' side, ``other''
the new side).
@end deffn

@deffn UnitTypeProperty @code{revolt-morale} fp
@end deffn
@deffn UnitTypeProperty @code{revolt-own-feeling} fp
They are applied when u revolts.
@end deffn

@subsection Charm

This action can model magic spells, terrorism, psychological weapons,
propaganda, bribes, etc.

@deffn ActionType @code{charm} unit
This is the action that a unit performs to modify the @code{morale} and
@code{feelings} of another unit.  The unit must be visible and within
@code{charm-range} to be charmed.
@end deffn

@deffn UnitTypeProperty @code{charm-range} dist
Defaults to @code{1}.
@end deffn

@deffn Table @code{charm-friend-chance} u1 u2 -> n%
The chance of charming a friendly unit.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-enemy-chance} u1 u2 -> n%
The chance of charming a hostile unit.
Defaults to @code{0}.
@end deffn

@deffn Table @code{acp-to-charm} u1 u2 -> acp
This is the number of acp a unit uses to do one charm action.
Defaults to @code{1}.
@end deffn
@deffn Table @code{charm-consumption} u1 m -> mp
This is the amount
of u1's supply used up in one charm action.
m is usually something like @code{"mana"} or @code{"gold"}.
Defaults to @code{0}.
@end deffn

@deffn Table @code{charm-morale} u1 u2 -> fp
Added to u2's @code{morale} if charm is successful.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-own-feeling} u1 u2 -> fp
Added to u2's @code{feelings} towards its side if charm is successful.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-other-feeling} u1 u2 -> fp
Added to u2's @code{feelings} towards u1's side if charm is successful.
Defaults to @code{0}.
@end deffn

@subsection Relaxation

@deffn UnitTypeProperty @code{morale-relaxation} n
@end deffn
@deffn UnitTypeProperty @code{own-feelings-relaxation} n
(for the unit's own side)
@end deffn
@deffn UnitTypeProperty @code{other-feelings-relaxation} n
(for all the other sides)

They default to @code{100}.
@end deffn

At the and of each turn, the old values of @code{feelings} and
@code{morale} are multiplied by (the appropriate) n/100; then all the
previous modifiers are added; the result is rounded to an integer in the
usual (stochastic) way to obtain the new @code{feelings} and
@code{morale}.

@subsection Missing

@code{revolt-chance} modifier for occupants (and nearby units).  Then,
using with @code{revolt-chance-modifier} and assuming that a
newly-captured unit retains a ``bad'' feeling towards the old enemy, you
will have to guard a newly-captured unit (with your ``secret police''?)
until its feeling towards you improves.

Effects of side behavior: d.o.w. or breaking a treatise should modify
feelings of (certain) units.

Effects of weather.
(end of proposal)

--X11 Interface

SelFile should be configured in with with-selfile, only built
and linked in if configured and present.  Fix nonportabilities
like decl of sys_errlist, etc.

Colorize unit icons via u_color().
Allow either use of side colors (symbolically, %1, %2, etc
matching against side color array elts, or by name).

List of unit types should gray out types that can't be owned by
the player.  Add option to eliminate any that can't be in game
at all (designer will need to see all types though).

Players should be able to indicate a willingness to declare a draw.
should display other sides' willingness to draw.

Use special bg pattern or stipple for unseen and grid colors if mono.
(or - support {lt,md,dk}gray on mono displays, in addition to other patterns.

Let imf2x only extract bitmaps whose names match given arg.

Add resource name to request_color, use to override standard
color choices.

Add resources:
    -xrm
    -display (for player starting the game)
    -fn, -font (text font only)

Use Xconq.game.<game>.<unit>.{char,image,color} to set per-game colors etc.

Use Xconq.{map,worldmap}.draw{Terrain,Grid,Style,Units,People,...}
to set appearance of new maps.

Add side->ui->default_drawunits etc to set initial values for each
created map, let these be settable from resources.

Fix drawing to not damage borders or else redraw as needed.
What rules for which should lay on top of which?
Try to optimize so border redrawing not always being done.

Default unit images should include first few chars of name in box,
a la Mac interface.

Allow setting of window subdivisions via resources.
Xconq.map.listWidth: <pixels>
Xconq.map.notesHeight: <lines>

Add good features of 5.5.

Develop a higher-contrast more-visible display of current unit/location.

Typing text into ask_position switches to prompt, reads a textual spec
of location.

Allow terrain color to be two colors, use to colorize mono bitmap
for terrain.
Search for ',' in t_color, fg first, then bg, assume bg is black if
not given.  Need a way to reverse so fg is black and bg colored.

imf2x should indicate progress, never overwrite existing images
(or compare - effectively "move-if-change" behavior)

Use a builtin color matching a color name if possible, otherwise
use the imc definition.

Write image scalers for *2 and /2 size images, compute and cache during
startup.  Shrink rule is 0,1 -> 0, 2,3,4 -> 1.

Main game help should include lists of types and their most important
properties.

To describe movement abilities, display both acp and "move range over
a given terrain type", which may be much less.

Non-tiling terrain patterns should be centered in cell on top of another
pattern/color possibly.  How to scale to larger cells?

Lists of units should also be able to display glimpses, just omit data
that is not available (what about names? might be tough to save names
with glimpses)

A hex consists of the hex and a unit display area entirely inside.
Only magnify unit images up to a point, not always to fill hex
(should make proportional to stack capacity).

Never try to auto-calculate hex chars from fill patterns,
but maybe provide a simple tool, goes with tool to build
font from bitmaps?

Font should support terrain pattern inside colored hex - needs to be
precomputed when building the font.  If not avail, still have to draw
twice.

If names displayed on map, use different size (and type?) fonts
for different kinds of units.
Legend fonts should vary with magnification also.

Decide who will see terrain changes in general, and weather/season
effects.  Need always-seen for these things, use coverage arrays as well.
Also allow for varying reliability and completeness of this.

What to do about area painting and dragging?  Turn on pointer motion
events temporarily?  Look at "bitmap" source.

Make the font stuff work again.
Define a family of "xconq" fonts, one (or two?) for each size, pack in
icons, masks, terrain.  Eventually allow more than one font at each size,
in case too many images.  Concentrate on terrain at first...  Keep separate
file with char->image mapping, read in from a standard place at startup.
(Install in program? No, can't update when font is updated)

For event list display, maintain buffer of n lines, each pointing to
event being listed, recalc when window enlarged, etc.
When list[i] selected, display event description plus ptrs
to related events.
Some "events" will be summaries (like total losses),
be able to change amt of summarization.
Observer mask is parenthetical remark.
Include toggles to display events as they come in, and
to scroll map to show where event is happening.

Change setup to use a single popup; list of games and preview at top,
then variants (min size initially, then grow for actual variants),
then player list and buttons.
Use cmdline to fill in as much as possible.
Highlight stage as committed to.
Confirm openability of each display when typed in.
Xconq.setup:
Xconq.setup.game:
Xconq.setup.game.list:
Xconq.setup.game.description:
Xconq.setup.game.picture:
Xconq.setup.game.loadbutton:
Xconq.setup.variants:
Xconq.setup.variants.{things}:
Xconq.setup.variants.ok:
Xconq.setup.variants.cancel:
Xconq.setup.players:
Xconq.setup.players.list:
Xconq.setup.players.{aibutton,etc}:
Xconq.setup.ok:
Xconq.setup.cancel:

Dynamically allocate more of the ui struct of each side.

--Macintosh Interface

Add explicit test for cicn 256, warn if one exists.

Fix to beep if a unit ordered to attack but has no ammo available.
Should also pop up or otherwise make a warning visible.

Fix scrolling confusions in history window.

Fix scrolling confusions in list window.

Add option to display terrain as solid colors if colors are available.

Don't require resignation if quitting while a designer.

Define and use an "erase-in-the-grid" procedure.

Build Mac docs from combined Mac-specific and generic player info.

Add a "completed units only" option to list view.

Display GPL somewhere at startup.

Don't force update or redraw of windows if clicking a button has no
visible effect (wrong mag for instance).

Don't redraw unchanged scores.

Ensure that "computer" and "face" icons updated when side info changes.

Interp arg to 'P' as number to build, seed from doctrine.
'P' should bring up modal dialog?

In IMFApp, separate "color/mono" from "cqd available" display options.

In IMFApp, "Open..." should preselect imf.dir if exists.

In list, add column that indicates current task.

Disable "give" menu entirely if giving not allowed.

Attach version resources to all components of Mac binary distribution.
Do with MPW script that recurses through all files.

Change of map magnification should automatically set window to user state.

Add machinery to display/write out final statistics.
(Use standard name "stats.xcq".)
Choice to write should be preference, or else ask when game is over.

Display range of possible advantages in player dialog, allow setting via
popup or text box as well as up/down arrow.

Add numerical display option for sides, set up 8x8 or 6x8 number emblems.
Also allow larger sizes of numerals (12x12 or 9x12).

Save sound on/off state as part of "ui-data" save, plus save window info,
flagged as Mac-specific, so can play under X for awhile, drag back to Mac
and get same setup, drag to X again and get X setup again.

Eliminate occasional need to click a second time to get a build to happen.
(Probably because unit hasn't come up in execution order yet.)

Add rubberbanding to world shape/size dialog.

Don't redraw all controls when updating designer dialog.

Support large numbers of sides in setup by adding a scroll bar between list of
sides and the buttons.

Draw side progress bars incrementally when possible.

Describe not-yet-arrived units correctly in list windows.

Check for events between every few rows of drawing, be able to abort or restart
drawing if requested.

Make designer palette into a floating window.

Do mouse-based actions when mouse *released*.

Use unit->uihook to optimize re-selection of units in maps.

Clicking in construction should cause next window back to scroll/hilite
selected unit (or add a button to do?)

Use drag of unit to indicate waypoints of a path, feedback with envelopes
of route and only do waypoints when indicating points outside shortest route.

Be able to double-click in build dialog to set construction .

When laying out list window, precompute widths of columns using max/expected
string widths for type names etc.  Account for width of headers and desired
spacing between columns.

Make pdoc load game and print the full description of it.

Allow multiple units to be selected in list windows.

Express merge by dragging onto unit, express detach by supplying an amount
in modal dialog (awkward, but rare?)

Should be able to zoom or resize side list to show relative standings and
other detail about each side.

Allow for more flexibility in size of emblem relative to unit (a preference?)

Display instructions and notes from multiple modules possibly, need to say
how to do this (explicit "append" directive at end of instructions?).

Implement a progress bar for internals of AI calcs or at least a watch cursor.

Extend construction dialog to include material production.

Build routines to insert a string into a "field" of a list entry,
instead of rebuilding entire entry.

Mark menus to indicate whether any of a group of selected units matches
each item.

Unhighlight forward/backward arrows when no units to look at.

Command-. should be able to interrupt nearly any calculation.

Preferences dialog should have a list of specific setups to choose from
("big screen", "careful play", etc) impl as config-names.  Player config
objects should include Mac-specific flags then...  Dialog can also have
several screens of options.

To display names, make a layer of shorts where each value is location of
cell with the legended object.  Cell itself has access to legend, plus
flag indicating direction and position of beginning of legend.  Then to
erase legend, have to clear each cell that refers to given cell.
Also need to repair legend correctly when another unit passes through it.

When drawing rubberband line for movement, make line heavier for part of
movement that will happen immediately.

World is totally lit if dimensions < half of world circumference and all
six corners of hexagon have same lighting.  If world totally dark, draw
darkening mask only.

When listing units by location, add twist-down for occupants, group stack
members with bar or some such.

Be able to draw more unit info on map window, at least at high mag powers.
Do num parts/hp, mp/acp, in misc corners a la Empire Master.  Unit id would
be useful also sometimes.

Implement both randomly-chosen and cycling image sets for the map window.

Support multiple sounds - ones for attack, hit, death, use diff ones
for shooting, possibly movement noises.
Should be able to define special win/lose sounds (cheers and raspberries),
attach to interface's handling of events from kernel.

Implement images and sound effects for combat (at different scales, so
need to incorporate into imf machinery).

To indicate available movement, change cursor to reflect accessibility
and amount of time needed to get there (ETA) or display in control panel
or elsewhere on map.

Implement doctrine as dialogs examining doctrine objects.
Add button in unit closeups.

Do offscreen drawing for visible map plus part of area around, but need
to calc memory limits so as not to exhaust space prematurely.  Do one
offscreen area/map, precalc size and retain, use individual cell drawing
otherwise.

To draw maps while still allowing events, make an array of rows for each map.
Update event computes which rows to redraw, plus start/end of each (use 0/0
to indicate no drawing needed).   Then in main event-handling loop, if rows
remain to be drawn, do one or a few ("draw rows for 15 ticks") then go back
to wait for event.  Only call run_game when a) all map rows are drawn, or
b) an event comes in from another machine.

Be able to hit key to bring up useful data while rubberbanding, or else have
additional popup with this info.

Add localizations for common languages.

Support distinct images for individual units, via a hook property.
Maintain id->image table (hash table? do sizes as well).

Add a graph window that displays up to 4-5 chosen statistics against time.
Needs choice of what to display and a subset selector for each graph.
Some stats will have records that have been kept, others will start only
when graph is requested, but then keep accumulating even if no longer
being displayed.

For Gettysburg, add movie showing rain descending on field at end of game.

Finish perspective display handling.

Add machinery (to MPW version) to build an integrated executable that
doesn't need lib or lib-mac.  Use sed/streamedit and Rez to make
resources from text files, plus renumber so no conflicts with
base resources.

--Windows Interface

Add one.

--NextStep Interface

Add one.

--Curses Interface

To describe movement abilities, display both mp and "move range over
a given terrain type", which may be much less.

When moving cursor modally, maintain some info about what exactly is under
the cursor (use whole info space, put info about what is being
moved in mode line).
Include info about distance from starting position, and support "direction"
cmds to cycle through stack.
Distinguish perm from temp top line data, keep track of each separately.

'D' doctrine, have it bring up textual summary, use textual commands to
modify.

To tweak display, use "[+-][utn]" to enable/disable units, terrain, names.

For event list display, maintain buffer of n lines, each pointing to
event being listed, recalc when window enlarged, etc.
When list[i] selected, display event description plus ptrs
to related events.
Some "events" will be summaries (like total losses),
be able to change amt of summarization.
Observer mask is parenthetical remark.
Include toggles to display events as they come in, and
to scroll map to show where event is happening.

Allow putting up a legend to display chars (such as terrain type chars)
in list area.  Bring up via '/' or perhaps option to general help.

If can support, add getch() timeout so human can move immediately instead
of waiting for mplayer to finish.  Indicate that mplayer is "thinking"
periodically, need kernel callback (?).

Add printing - just dump into something lpr'able.

Help topics should be formatted as multi-column list, let arrow keys
move around.

If a savefile is present and no contradictory args found (no -f, -g, -join),
ask the player if they wish to resume the saved game.

Ensure that all stdout/stderr stuff goes into a file so screen doesn't
get scrambled, even with debugging on. (copy Mac code)

Warnings should have a preference to record full text of warning in a file.
Full warning should more data at end of message, then truncate if too big
for alerts.  (If warning recording is on, mention in alerts or somewhere
that additional data is available in a given file.)

--DOS/VGA Interface

Add one.  (Xconq is fundamentally 32-bit code, so not much point in
trying to do anything less than i386 with VGA; in other words, use
DJGPP with libgrx.)